home *** CD-ROM | disk | FTP | other *** search
- Path: newsbf02.news.aol.com!not-for-mail
- From: frankeye@aol.com (FrankEye)
- Newsgroups: comp.lang.c++
- Subject: Composition Insights Please!
- Date: 23 Jan 1996 14:37:35 -0500
- Organization: America Online, Inc. (1-800-827-6364)
- Sender: root@newsbf02.news.aol.com
- Message-ID: <4e3ddv$nnp@newsbf02.news.aol.com>
- Reply-To: frankeye@aol.com (FrankEye)
- NNTP-Posting-Host: newsbf02.mail.aol.com
-
-
- Can anybody share any insightful guidelines regarding the employment of
- class composition (a.k.a. "aggregation") in C++? I know the difference
- between it and inheritance. I was surprised by the lack of mention or at
- most the mere acknowledgement of composition in the C++ FAQ (both online &
- book), Lippman's Primer, ARM, and Designing & Coding Reusable C++
- (Carroll&Ellis).
-
- +++++++++++++
-
- One guideline I've come across is the "Law of Demeter", which asserts that
- the methods of a composite (aggregate) class should only be aware of the
- members of its immediate component classes, and not attempt to talk to the
- once-removed interfaces of its components' components. For example,
- consider the manipulation of a hierarchical geometry model within a
- CAD/Visualization program:
-
- /* Below conforms to Law of Demeter */
- class Vehicle {
- composed of Parts (implemented as a List of class Part)
- void setPitchAngle(double& pitch) {parts -> setPitchAngle(pitch)}
- }
- class Part {
- composed of Patches (implemented as a List of class Patch)
- void setPitchAngle(double& pitch) {patches -> setPitchAngle(pitch)}
- }
- class Patch {
- composed of Facets (implemented as a List of class Facet)
- void setPitchAngle(double& pitch) {facets -> setPitchAngle(pitch)}
- }
- class Facet {
- composed of Ordered Vertices
- void setPitchAngle(double& pitch) { // rotates vertex coordinates }
- }
-
- The above example illustrates the proliferation of "traversal code" which
- is the gluecode necessary for the design of aggregate (composite) classes
- to comply with the Law of Demeter. For aggregate classes, traversal code
- is comprised of those member functions at the aggregate class level which
- access or manipulate the state of the component member classes. Notice
- that at each level in this example, one may identify an aggregate class.
- Such nested aggregation, which may be desired in order to isomorphically
- model the problem domain, is also the cause of many redundant small
- methods (e.g., setPitchAngle()) which exist merely to "propagate" a method
- down to the component class elements which actually "do the work" or are
- worked upon.
-
- Why not merely implement setPitchAngle() as a singular function within the
- Vehicle class and eliminate the intermediate traversal code?, e.g.:
-
- /* Violates Law of Demeter */
- void Vehicle::setPitchAngle(double& pitch) {
- for all parts i:
- for all patches j of part[i]:
- for all facets k of patch[j]:
- part[i].patch[j].facet[k].setPitchAngle(pitch);
- }
-
- The answer supporting the Law of Demeter, I suppose, is that such code is
- brittle in the face of modifications to the class composition hierarchy,
- e.g., if we later decided that a Part->composed of->Assemblys->composed
- of->Patchs instead of Part->composed of->Patchs. Depending on the depth
- of the composition nesting, it may in general be more expensive to fix
- code such as the above, rather than fix/insert traversal code only at the
- broken boundaries of the composition graph.
-
- In fact, I was made aware of the Law of Demeter by a student of Prof. Karl
- Lieberherr of Northeastern Univ., who has presided over the creation of
- the "adaptive software" method captured in his Demeter/C++ Tools set.
- This "Demeter method" eliminates the manual generation and maintenance
- (resulting from changes, enhancements to class composition graph) of
- traversal code, by making use of graph traversal methods from aggregate
- class nodes (e.g., Vehicle) via any encountered component classes to
- destination class nodes (e.g., Facet).
-
- ++++++++++
-
- Has anybody out there benefitted by conforming to the Law of Demeter? Are
- there any other design issues regarding composition?
-
-
-
- Frank J. Iannarilli, Jr.
- frankeye@aol.com OR franki@aerodyne.com
-